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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The present document is part 2 of a multi-part deliverable covering the IP Datacast Electronic Service Guide 
implementation guidelines over DVB-H and DVB-SH as identified below: 

Part 1 : Part 1 : IP Datacast over DVB-H; 

Part 2: Part 2: IP Datacast over DVB-SH. 



Introduction 

IP Datacast is an end-to-end broadcast system for delivery of any types of digital content and services using 
IP-based mechanisms. An inherent part of the IPDC system is that it comprises a unidirectional DVB broadcast path 
and a bi-directional mobile/cellular interactivity path. IPDC is thus a platform for convergence of services from 
mobile/cellular and broadcast/media domains. The present document gives the implementation guidelines on the use of 
the Electronic Service Guide in IP Datacast over DVB-SH system. [2] is a corresponding document guidelining on the 
use of Electronic Service Guide in IP Datacast over DVB-H system. 
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Scope 



The present document gives implementation guidelines on the use of the electronic service guide in IP Datacast over 
DVB-SH system ( [4] to [6]) for the announcement of services to the terminal. 

The present document intends in particular to guide implementers of IP Datacast over DVB-SH Services, Servers and 
Terminals to make best use of the specification IP Datacast over DVB-H: Electronic Service Guide 
TS 102 471 [1]. The document must also be considered as complementary to the implementation guidelines applicable 
in DVB-H context [2], in particular for supporting ESG regionalization, one of the specific features provided by a 
DVB-SH network. 

The prresent document is structured into three main clauses. Clause 4 provides an overview of hypothesis and 
requirements followed in the DVB-SH context. Clause 5 describes how regionalization can be ensured in some specific 
scenarios. Annex A provides guidance on different types of ESG implementation, including DVB-H, and their 
interoperability. Annex B provides more details on the DVB-SH network physical capabilities. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 471 (Vl.2.1): "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: 

Electronic Service Guide (ESG)". 

[2] ETSI TS 102 592-1 (VI. 1.1): "Digital Video Broadcasting (DVB); IP Datacast: Electronic Service 

Guide (ESG) Implementation Guidelines; Part 1: IP Datacast over DVB-H". 

[3] IP Datacast over DVB-H: Electronic Service Guide (ESG) - A099rl (dTS 102 471 vl.3.1). 

[4] ETSI TS 102 585: "Digital Video Broadcasting (DVB); System specifications for satellite services 

to Handheld devices (SH) below 3 GHz". 

[5] ETSI EN 302 583 (VI. 1.1): "Digital Video Broadcasting (DVB); Framing Structure, channel 

coding and modulation for Satellite Services to Handheld devices (SH) below 3 GHz". 

[6] ETSI TS 102 584: "Digital Video Broadcasting (DVB); DVB-SH implementation GuideHnes". 
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2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i. 1] ETSI TS 102 472 (VI .2. 1): "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: 

Content Delivery Protocols". 

[i.2] ETSI TS 102 591 (VI. 1.1): "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: 

Content Delivery Protocols (CDP) Implementation Guidelines". 

[i.3] ETSI TS 102 470-2: "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 2 : IP Datacast over DVB-SH". 

[i.4] ETSI TS 102 611-2: "Digital Video Broadcasting (DVB); IP Datacast: Implementation Guidelines 

for Mobility; Part 2: IP Datacast over DVB-SH". 

[i.5] DVB A131 (1 1/2008): "MPE IFEC Specification". 

NOTE: Intended as annex to ETSI EN 301 192. 

[i.6] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[i.7] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[i.8] ISO/IEC 13818-1: "Generic coding of moving pictures and associated audio information: 

Systems". 

[i.9] IETF RFC 3926: "FLUTE - File Delivery over Unidirectional Transport". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

acquisition information: information necessary to acquire a service or content 

common service: service available on all cells where the TS is transmitted 

content: atomic content part of the service described, and scheduled separately 

delivery area: abstract area enabling to decouple the generation of regionalized ESGs from the knowledge of physical 
transmission areas 

NOTE: The ESG provider defines delivery areas and binds the IP streams scoped by an ESG to these delivery 
areas. Some network entity binds these delivery areas to cells in the network, via DVB service 
management and SDT generation. 

delivery area ID: integer value uniquely identifying a delivery area in the scope of a {TS, ProviderURI} 

elementary stream: stream of transport packets within a transport stream sharing a common Packet Identifier (PID) 

NOTE: The elementary stream definition differs from the one defined in MPEG-2 (ISO/IEC 13818-1 [i.8]). 
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ESG access descriptor: in the bootstrap session, descriptor providing the Hnk between the declaration of the ESGs (in 
the ESG Pro viderDisco very descriptor) and their respective acquisition entry point (the announcement carousel) 

ESG announcement carousel: FLUTE session used as an entry point by the terminal to acquire a given ESG 

ESG auxiliary data: ESG data, which is referenced from an instance of the XML based data model, e.g. an SDP file, 
an HTML page or a PNG file 

NOTE: Even though SDP files can be considered as ESG auxiliary data, it is possible to transport them within the 
ESG fragment stream or as files within a FLUTE session. 

ESG bootstrap session: FLUTE session used as an entry point by the terminal to discover the ESGs available in a 
given IP platform of the actual TS 

ESG container: structure to group ESG data into one transport object for delivery purposes 

ESG Entry: in the ESG Access descriptor, entry providing the tuning parameters of one announcement carousel 

ESG fragment: fragment of ESG data delivered in the ESG fragment stream and referred to by a fragment reference in 
the encapsulation structure 

NOTE: Namely an ESG fragment can be an ESG XML fragment, ESG auxiliary data or private auxiliary data. 

ESG Fragment ID: URI uniquely identifying a fragment in one ESG 

ESG init container: ESG container carrying data structures for initialization, such as the ESG init message and the 
ESG main fragment 

ESG init message: initialization information to decode ESG fragments 

ESG ProviderDiscovery descriptor: in the bootstrap session, descriptor providing information on ESGs available in a 
given IP platform of the actual TS 

ESG session partition declaration: tells the terminal, how the ESG is partitioned in ESG Sessions, what are the 
partitioning criteria for each session 

ESG XML fragment: ESG fragment of an XML instance which is an instantiation of a datatype 

NOTE: A limited set of ESG XML fragment types have been defined in TS 102 471 [1]. 

IP/MAC stream_location_descriptor: INT descriptor providing the locations of the instances (IP streams) of one IP 
flow in the actual Transport Stream and the neighbouring Transport Streams 

NOTE: This descriptor is especially used by the terminal to perform two procedures: 

■ IP address -^ PID resolution; 

■ handover decision making. 

IP platform: set of IP flows managed by an organization 

NOTE: The IP platform represents a harmonized IP address space that has no address collisions. The concept of 
IP platforms is described in more detail in TS 102 470-2 [i.3]. 

IP flow: flow of IP datagrams each sharing the same IP source and destination address 

Local service: service available on some cells (but not all cells) where the TS is transmitted 

private auxiliary data: data of which the format is not specified in TS 102 471 [1] 

providerURI: unique identifier of an ESG Provider 

NOTE: When referring to TS 102 471 [1] and TS 102 592-1 [2], it also uniquely identifies one ESG. 

providerlD: integer value used as a shortcut to designate a ProviderURI 

purchase channel: purchase system, through which a service may be purchased 
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purchase information: information to display to the user that a service needs to be purchased and the information that 
is necessary to access and acquire rights to consume a service or content 

purchase item: service bundle to which pricing information is attached 

schedule event: broadcast event which is described separately 

service: offer from a service provider and has media content related to it 

service: service offering e.g. Broadcast TV Channel, soap opera service 

servicelD: fragment identifier of a Service fragment. It can also be a partition criterion in the ESG session partition 
declaration 

service_avaiIabiIity_descriptor: SDT descriptor that may be included in a service entry of an SDT sub-table, to signal 
that the related DVB service is subject to cell-based transmission restrictions 

service bundle: group of services composed respectively offered by a single party 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

DVB Digital Video Broadcasting 

DVB-H Digital Video Broadcast - Handheld 

DVB-SH Digital Video Broadcast - Satellite to Handheld 

ESG Electronic Service Guide 

FLUTE File deLivery over Unidirectional Transport 

lANA Internet Assigned Numbers Authority 

ID IDentifier 

INT IP Notification Table 

IP Internet Protocol 

IPDC IP DataCast 

MPEG Moving Picture Expert Group 

NIT Network Information Table 

paTS partially available Transport Stream 

PID Packet IDentifier 

PNG Portable Network Graphics 

PSI/SI Program Specific Information/Service Information 

RFC Request For Comments 

SDP Session Description Protocol 

SDT Service Description Table 

SEN Single Frequency Network 

TS Transport Stream 

TSI Transport Session Identifier 

TV Television 

URI Uniform Resource Identifier 

WEB last part of world wide WEB 

XML extensible Markup Language 
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Hypothesis 



The DVB-SH provides different possible physical network configurations described in TS 102 584 [6], some of which 
are recalled in annex B. 

SFN configuration (DVB-SH A SFN) is actually strictly identical to TS 102 471 [1] in terms of ESG. Non-SFN 
configurations are new compared to TS 102 471 [1] in the sense that two frequencies (the satellite and the terrestrial) 
are used to distribute same TS. Therefore, due to the possibility to configure the physical layer differently between the 
two frequencies, some form of content regionalization is possible and described in TS 102 584 [6]. In this case, ESG is 
more complex than TS 102 471 [1] and there are new requirements: 

• The terminal MUST be able to differentiate from the ESG what content is provided where; in particular the 
satellite content SHALL be found in any locations, whether satellite or terrestrial, whereas the local content 
MAY be available in only selected locations; this information SHOULD be available to terminals so that they 
do not, for instance, attempt to display content that is not available. 

• Satellite bandwidth MUST not be overloaded with ESG data dedicated to announce local content; therefore 
some form of "partitioning" between ESG bootstrap sessions, ESG announcement carrousels, ESG fragment 
FLUTE sessions SHALL be ensured. 

• Service continuity SHALL be possible so that a terminal moving from the satellite area to a terrestrial area 
having different ESG conditions shall be able to complement but not contradict the already received ESG by, 
e.g. the local one (and vice- versa). 

• ESG distribution SHOULD allow a terminal located on one area to receive ESG fragments pertaining to an 
adjacent area. 

To support these additional requirements, some new innovative features are introduced such as delivery areas and 
explicit and implicit ESG fragment tagging. In the remaining of the document, we shall refer to the term "ESG 
regionalization" to designate the mechanisms allowing first a global ESG instance to announce common and local IPDC 
services, and second this ESG instance to be partially delivered on some areas depending on local IPDC services 
availability as well as bandwidth considerations. The present document therefore describes the guide lining of 
TS 102 471 [1] in order to support ESG regionalization for those DVB-SH scenarios that support it. 

It is assumed that such recommendations pertain to the only DVB-SH networks and terminals, excluding any DVB-H 
terminals to receive in any circumstances such forms of ESG instantiations. Therefore interoperability with DVB-H 
ESG is not primarily targeted although the foundations are strictly compliant and some form of compatibility between 
DVB-H ESG clients and DVB-SH ESG is possible Therefore the present document proposes several types of network 
(ESG server) and terminal (ESG client) implementations, all interoperable with each other, with some functional 
limitations in some cases. These implementations are detailed in annex A. 



5 ESG regionalization 

5.1 Detection procedure (on terminal side) 

All types of terminals (see annex A) can normally acquire non-regionalized ESGs as defined in TS 102 471 [1] and 
TS 102 592-1 [2]. 

In addition, for regionalized ESGs: 

• A Type terminal, although not capable of detecting that an ESG is regionalized, will seamlessly tune to the 
common announcement carousel and acquire the common components of a regionalized ESG (and in final will 
be able to tune to common IPDC services, while not being aware of the existence of local IPDC services). 

• A Type 1 or Type 2 terminal will detect that an ESG (identified by a given ProviderURI) is regionalized if for 
the associated ProviderlD it encounters multiple consecutive ESGentries in the ESG Access descriptor. 
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5.2 Specification 
5.2.1 Overview 
5.2.1.1 Principles 

This clause presents the principles of ESG for DVB-SH. 

The Partially Available Transport Stream carries the IP flows of one single IP platform. 

For a given ESG Provider URI, there is one single ESG, spanning over all the cells on which the TS is transmitted. 
However, since the TS is filtered on some of these cells, only a portion of this ESG will be valid on one given cell 
(i.e. a portion of this ESG will declare IPDC services actually available on this cell). When moving to another cell, the 
terminal acquires new portions of the ESG, complementing the other portions acquired in previous cells. 

The received TS comprise common DVB service(s) and eventually local DVB service(s). There is no explicit signalling 
for conmion and local DVB services in a Partially Available TS, however for sure the DVB service carrying the ESG 
bootstrap FLUTE session is a common DVB service. 

A non-regionalized DVB-SH ESG is a DVB-H compliant ESG as defined in TS 102 471 [1] and TS 102 592-1 [2]. A 
regionalized DVB-SH ESG is characterized by the presence in the ESG Access descriptor of multiple ESGentries 
associated with the providerlD identifying the ESG, each ESG Entry declaring one ESG announcement carousel. In the 
received TS, only one (one common) or two (one common, one local) of these ESG announcement carousels are 
actually transmitted, as signalled by INT and SDT. The terminal using an IP stream availability function (designed to 
check the actual transmission of some given IP stream(s) of a given IP platform ID) can determine which announcement 
carousels are actually transmitted in the TS. In case two ESG announcement carousels are transmitted, the terminal 
selects the local ESG announcement carousel, not the common ESG announcement carousel (how to distinguish each is 
specified hereafter). Indeed, the local ESG announcement carousel announces local and common ESG FLUTE sessions, 
whereas the common ESG announcement carousel announces common ESG FLUTE sessions only. 

The selected ESG announcement carousel declares multiple ESG FLUTE sessions via the ESG session partition 
declaration of the ESG Init Container. In this partition declaration, the declared ESG FLUTE sessions may be carried in 
any transmitted DVB service, and will at least include the common ESG FLUTE sessions (the ones carried in common 
DVB services), since all fragments delivered in common ESG FLUTE sessions are of interest on all cells. How ESG 
FLUTE sessions should be organized in the Transport Stream is guided by two considerations: firstly share FLUTE 
sessions between ESG announcement carousels whenever possible (instead of duplicating them), and secondly allow 
fine-tuned ESG complementing scenarios over broadcast channel. 

In order to decouple regionalization of ESG data from below-IP transport information and network infrastructure 
information, the concept of "delivery area" is introduced. Basically, the ESG provider groups in distinct "virtual" 
delivery areas the IP flows scoped by the same ESG instance (from ESG bootstrap session down to audio/video/key 
streams), and some entity in the network (generally the network operator) has the responsibility to bind each delivery 
area to a given set of cells in the DVB-SH network, which is technically achieved using the indirection of DVB service 
allocation and SDT generation. The delivery area is scoped by the ProviderURI, and has a unique ID in this scope. The 
delivery area IDs are not used the same way on network side and terminal side. On network side, the TS encapsulator 
needs to know the delivery area ID of each session so to correctly decide on the grouping of IP streams in DVB 
services, whereas on terminal side the terminal needs only to determine the delivery area ID of the announcement 
carousels. 
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For a Type 1 terminal: 



The concept of delivery area is not directly used. The terminal first builds an implementation- specific identifier for each 
ESG FLUTE session (e.g. based on TSI, source IP address, destination IP address, etc) transmitted for the selected 
announcement carousel. Then at the time of storage, each fragment is tagged by the terminal by the identifier of the 
FLUTE session which delivered the fragment. When browsing the ESG on any cell, and knowing the ESG FLUTE 
sessions currently transmitted for the selected announcement carousel, the terminal can quickly retrieve from the stored 
ESG which fragments are presumably valid to be presented to the user, i.e. which fragments announce IPDC services 
that are actually available on current cell. However since the ESG provider may choose to deliver in ESG FLUTE 
sessions some fragments which are not valid on current cell, and since a Type 1 terminal does not know if the ESG 
provider delivers such fragments, the terminal, before tuning to any IPDC stream, must systematically check for the 
availability of these IPDC streams using an IP stream availability function. 

The tagging mechanism is called "implicit ESG fragment regionalization based on FLUTE session identifier", implicit 
because not signalled in the fragment payload itself. 

Fragments not tagged by the current FLUTE session identifiers are for sure not valid on current cell, fragments tagged 
by any of the current FLUTE session identifiers may be valid on current cell, and an additional availability check on the 
IPDC streams declared by the tagged Acquisition fragments is needed to confirm this validity. Said otherwise, this 
FLUTE session ID-based tagging reduces the number of IP stream availability checks for Type 1 terminals. 

For a Type 2 terminal: 

The concept of delivery area is directly used to determine which acquired ESG fragments of the ESG instance are valid 
on the current cell. At the time of storage, each fragment is tagged by the terminal by a delivery area ID, which 
represents the delivery area where this fragment is valid. When browsing the ESG on any cell, and knowing the IDs of 
the delivery areas it is currently located in, the terminal can quickly retrieve from the stored ESG which fragments are 
valid to be presented to the user, i.e. which fragments announce IPDC services that are actually available on current 
cell. 

The main tagging mechanism is called "implicit ESG fragment regionalization based on delivery area ID", implicit 
because not signalled in the fragment payload itself. Generally this mechanism consists in tagging the fragment by the 
delivery area ID contained in the "servicelD" criterion of the partition that declares the ESG FLUTE session delivering 
the fragment. 

However, implicit ESG fragment regionalization implies some restrictions and prevents ESG complementing scenarios 
that can help ESG acquisition service continuity. The tagging of individual fragments called "explicit ESG fragment 
regionalization based on delivery area ID" can therefore be used as a complementary mechanism. For this, ESG for 
DVB-SH proposes to encode the delivery area ID in the URI of the fragment ID, and in the URI of ESG Auxiliary Data. 

5.2.1.2 Example 

Figure 1 illustrates an example of ESG for DVB-SH. Taking the case where the transmitter transmits the Partially 
Available TS on a cell belonging to "Terrestrial Group of Cells 1", it will transmit DVB services 14, 5 and 53, but not 
DVB service 11 (filtered). 

A Type terminal will behave like a DVB-H ESG client and select the first ESG Entry matching the selected 
ProviderlD. As this first ESG Entry declares the common ESG carousel 0, this terminal will seamlessly tune to this 
carousel and then to the related common ESG FLUTE sessions. The terminal will then tune to the common IPDC 
services, while ignoring the existence of local IPDC services. 

A Type 1 or Type 2 terminal will detect that the selected ESG (ProviderURI) is regionalized by the presence of multiple 
ESGentries given for the related ProviderlD. The terminal will use a (typically low-level) IP stream availability function 
to determine which announcement carousels are transmitted. Internally this function will find in the INT one matching 
target_IPxx_address descriptor for each declared carousel. The IP/MAC stream_location_descriptor of carousel 2 
(224.10.8.37) will indicate that this IP stream belongs to DVB Service 11, and service_availability descriptor in SDT 
will indicate that this DVB service 1 1 is filtered. Thus, the terminal can conclude that carousel 2 is not transmitted. 

From the two addresses remaining (224.3.2.04 and 224.7.1.12), the terminal will select 224.7.1.12 since appearing 
second in the ESG Entry loop. ESG announcement carousel to be monitored is then on this remaining address 
224.7.1.12 carried on DVB service 5. 
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The subsequent selection and tuning to ESG FLUTE sessions follows IPDC phase 1 rules. In order to achieve implicit 
ESG regionalization later on, the terminal needs in addition to remember some delivery information (for Type 1 
terminals: the FLUTE session identifier of each monitored ESG FLUTE session; for Type 2 terminals: the delivery area 
ID of the selected carousel, as well as, for each monitored ESG FLUTE session the delivery area ID contained in the 
"servicelD" criterion of the partition declaring this session). 
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Figure 1 : Example of ESG transport in a DVB-SH Partially Available Transport Stream 

Some comments on figure 1 : 

• Relationship between ESG FLUTE sessions and IPDC services is not represented because this relationship is 
potentially complex (for example an Acquisition fragment distributed in an ESG FLUTE session of Delivery 
Area 1 can announce an IPDC service of Delivery Area 2 if it is explicitly tagged by delivery area ID = 2). 

• As illustrated, DVB service numbering is totally decoupled from delivery area numbering. 
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5.2.2 Transport Stream, delivery areas, ESG and IPDC services 
configurations 

5.2.2.1 Transport Stream configuration 

This clause explains how the network must configure the Transport Stream in order to deploy ESG for DVB-SH. 

The Transport Stream must carry the IP streams of one single IP platform. 

The Transport Stream must be composed of the following DVB services: 

• One common DVB service or more, available on all cells (satellite and terrestrial) where this TS is transmitted. 
In order to reduce PMT bitrate, the recommended configuration is one common DVB service. 



• 



One local DVB service or more, not available on some of the cells where this TS is transmitted. On a given 
cell, zero, one or more local DVB services may be transmitted. 



5.2.2.2 ESG sessions configuration 

In case of DVB-SH full Transport Stream, the constitutive DVB services are by definition all common, and: 

• the distributed ESGs can only be non-regionalized, i.e. they strictly comply with DVB-H ESG 
(TS 102 471 [1] and TS 102 592-1 [2]). 

In case of DVB-SH Partially Available Transport Stream, the constitutive DVB services are common and local, and: 

• the distributed ESGs announcing common IPDC services but no local IPDC services are typically not be 
regionalized (and then they strictly comply with DVB-H ESG as defined in TS 102 471 [1] and 

TS 102 592-1 [2]) however they can be regionalized also if it is wanted to use local DVB services to carry 
complementing common ESG data (see ESG instantation mechanism 5). 

• the distributed ESGs announcing common and local IPDC services must be regionalized. 

One common DVB service has the particularity of carrying the ESG bootstrap FLUTE session of the single IP platform 
of the TS (indeed it is recognized by the terminal as being common due to this particularity). For each ESG Provider 
URI, this DVB service must also carry the common ESG announcement carousel, which declares ESG FLUTE sessions 
transporting fragments valid for this ESG on all cells where the TS is transmitted. In case other common DVB services 
are transmitted, they must not carry ESG announcement carousels. For a regionalized ESG instance, ESG 
announcement carousels may also be carried by local DVB services. For a given ESG Provider URI, there must be at 
most one local ESG announcement carousel transmitted. Via the ESG session partition declaration, each local ESG 
announcement carousel can announce: 

• at least all the ESG FLUTE sessions announced by the common ESG announcement carousel; 

• other ESG FLUTE sessions carried by transmitted local DVB services. 

The ESGEntries of a given ESG Provider ID must be carried by one single ESGAccessDescriptor. An 
ESGAccessDescriptor can be shared by multiple ESG ProviderlDs. The recommended IPDC phase 1 configuration (one 
single ESGProviderDiscovery descriptor, one single ESGAccessDescriptor) satisfies this model. 

In this ESGAccessDescriptor, the ESGEntries of this ESG Provider ID must appear as a continuous sequence in the 
ESG Entry loop. In this sequence, the ESG Entry declaring the common ESG announcement carousel must appear first. 

ESG FLUTE sessions declared from the current announcement carousel must all be available in the transmitted portion 
of the Transport Stream (said otherwise, the terminal never needs to check for the availability of an ESG FLUTE 
session declared from the selected announcement carousel). This implies in particular that an ESG FLUTE session 
declared from the common announcement carousel must always be carried by a common DVB service. 
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5.2.2.3 Delivery areas 

A delivery area is a conceptual area defined to achieve regionalization of ESG data while at the same time decoupling 
ESG data and ESG sessions from below-IP transport information (like DVB service_id) and network infrastructure 
information (like cell_id). 

For the ESG provider and service provider, a delivery area is a transport-agnostic and network-agnostic conceptual area 
where a well-defined set of related ESG sessions and IPDC services are instantiated. Delivery areas are defined by the 
ESG provider, in the scope of one ESG instance (ProviderURI). 

For the Transport Stream originator or network provider, the delivery area is to be bound to an actual area of 
transmission in the DVB-SH network, i.e. in practice a subset of cells in the group of cells where the Partially Available 
Transport Stream is transmitted. The present document does not specify which entity in the network is in charge of 
defining this binding. 

For the (Type 2) terminal, the delivery areas are used in a more restrictive manner, for the basic purpose of determining 
which acquired fragments are valid on the current cell. Type and Type 1 terminals do not use delivery areas. 

The ESG providers must indicate to the entity building the TS the following: 

• For each IP stream (ESG sessions, other IPDC sessions), which ProviderURI/delivery area ID pair(s) it 
belongs to. 

• For each ProviderURI, what are the dependencies between the related delivery area IDs (e.g. area has no 
dependencies, area 1 has dependencies with area and area 500, etc.) 

From this information, the DVB services of the Partially Available Transport Stream can be safely constructed 
according to the following rules: 

IP streams assigned to delivery areas with ID = (regardless of ProviderURI) must be carried by common 
DVB service(s). 

IP streams assigned to delivery areas with ID ;^ (regardless of ProviderURI) must be carried by local DVB 
service(s). 

IP streams assigned to same ProviderURI/same delivery area ID must be carried by one single DVB service. 

IP streams assigned to same ProviderURI/different delivery area ID must be carried by different DVB 
services. 

IP streams assigned to different ProviderURIs may be carried or not in same DVB service. 

In the TS, the number of common DVB services and local DVB services should be minimal. 

In a last step, and given some specified binding between delivery areas and DVB-SH cells, it is possible to construct the 
SDT and the service_availability_descriptor (if relevant) for each service entry. 

Note that this binding is dynamic over time: 

• For a given ProviderURI/delivery area defined by the ESG provider, the network entity in charge of the 
binding can decide to change TS identification or DVB service structuring or transmission cell selection, and 
this change is transparent for the ESG provider. 

• For a given network binding (TS identification, DVB service structuring, transmission cell selection), a change 
of distribution area definition by the ESG provider (addition or deletion of an IP stream, change in distribution 
area dependencies) are likely however to impact at least on the DVB service structuring. 
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The delivery area is identified by 3 -digit identifier (called "delivery area ID") unique in the scope of an ESG instance 
(ProviderURI). Several ranges of values are defined: 

• 0: identifies the common delivery area targeted by the common announcement carousel. 

• 1 to 499: identifies a local delivery area targeted by a local announcement carousel. 

• 500 to 999: identifies a local delivery area targeted by no specific announcement carousel. This range allows 
some specific ESG instantiation mechanisms (6, 7 and 8). 

For the range to 499, the delivery area ID represents the index of ESG Entry declaring the targeting announcement 
carousel, index starting from zero in the continuous sequence of ESGentries assigned to the ProviderlD. 

EXAMPLE: 

In the ESG ProviderDiscovery descriptor: 

Pro viderURI=myPro V 1 . com Pro viderID= 1 8 

Pro viderURI=myPro v2.com ProviderID=2 1 

ProviderURI=myProv3 .com ProviderID=54 

In the ESG Access descriptor: 

ESGentry ProviderID=54 delivery area ID=0 for myProv3.com 

ES Gentry 1 ProviderID=54 delivery area ID=1 

ESGentry 2 ProviderID=21 delivery area ID=0 for myProv2.com 

ESGentry 3 ProviderID=21 delivery area ID=1 "" 

ESGentry 4 Pro viderID=2 1 delivery area ID=2 

ESGentry 5 ProviderID=18 delivery area ID=0 for myProvl.com 

ESGentry 6 ProviderID=18 delivery area ID=1 

5.2.2.4 IPDC services configuration 

Similar to TS 102 471 [1] and TS 102 592-1 [2], with the additional consideration that is the responsibility of the ESG 
provider to properly instantiate the ESG so that a terminal of any type (0, 1 or 2), using Acquisition fragments and 
related SDP files, is never in the situation where it attempts to tune to an IPDC stream for which there is no PID 
(i.e. case of a local IP stream not transmitted). If the ESG provider follows ESG instantation mechanisms described in 
clause 5.3, proper terminal implementations should not face this error situation. 

5.2.2.5 Explicit ESG fragment regionalization 

Explicit ESG fragment regionalization is a mechanism that Type 2 servers can apply to individual ESG fragments of 
regionalized ESGs, to explicitly signal the delivery area of validity of these fragments. This signalling consists in 
storing the ID of this delivery area in the fragment ID (URI) of the fragment itself. More specifically: 

• The fragment ID of a regionalized fragment must be a valid URI. 

• Unless otherwise stated below, construction of this URI should follow the guidelines provided by 
TS 102 592-1 [2], clause "Identifiers within ESG XML fragments". 
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In the URI, the pattern 'area999' (without quotes) must immediately follow the URI scheme (and the double 
slashes '//' if any), where 999 represents the 3-digit delivery area ID value in decimal representation (059, 002, 
etc). Valid examples are: 

somescheme : area059somecharacters 

dvbipdc : //area059 .myprovider/Channell/Contentl 

http : //area059 .myprovider . com/Channell/Contentl 

In line with TS 102 471 [1] and TS 102 592-1 [2], the present document does not mandate the use of a specific 
URI scheme in DVB-SH regionalized fragment identifiers. In any case, including the pattern 'area999' in the 
URI should satisfy the semantics defined by the URI scheme and should besides not trigger the obligation to 
register the area ID value with lANA or DVB, etc. In this regard, "urn:" scheme for a regionalized URI might 
not be a suitable choice, whereas "http:" scheme or "dvbipdc:" scheme (proposed in TS 102 592-1 [2]) would 
be. 

In a regionalized ESG delivered over DVB-SH, all fragment identifiers must use the same URI scheme. This 
constraint is meant to ensure that 'area999' pattern is included at a fixed position in all fragment identifiers of 
the same ESG. 

For non-regionalized ESGs delivered over DVB-SH (instantiated by Type and Type 1 servers): 

• ESG fragments must not be explicitly regionalized (i.e. 'area999' pattern must not be found in fragment 
identifiers). 

For regionalized ESGs delivered over DVB-SH (instantiated by Type 1 servers): 

• All fragment identifiers of the same ESG must use the same URI scheme. This constraint allows the terminal 
to find the 'area999' pattern (when present) at a fixed position in the fragment IDs of the same ESG. 

• All Service fragments of the ESG must be explicitly regionalized. This constraint is meant to enable proper 
definition and comparison of ESG session partitioning range values, as servicelD of Service fragment is one 
ESG session partition criterion: 

dvbipdc : //area059 . myp r ov ider /Channel 1/ 
dvbipdc : //area059 .myprovider/Channel2/ 
dvbipdc : //area002 .myprovider/Channel3/ 

• ESG fragments other than Service fragments must be explicitly regionalized whenever ESG instantiation 
mechanisms in use require so (as per clause 5.3). 

• Otherwise, ESG fragments may or may not be explicitly regionalized. If a fragment is not explicitly 
regionalized, delivery area ID of validity will be implicitly inferred by the terminal (implicit ESG fragment 
regionalization). Systematically applying explicit regionalization to all fragments simplifies fragment identifier 
generation, whereas relying on implicit regionalization (when possible) saves transport bandwidth and 
terminal storage space (at least 7 bytes per fragment). 

5.2.3 Terminal behaviour 
5.2.3.1 ESG Bootstrap 

5.2.3.1 .1 Tuning to ESG Bootstrap session of preferred IP platform 

Identical to TS 102 471 [1] and TS 102 592-1 [2]. 

5.2.3.1 .2 Selecting ESG provider URI from ESG ProviderDiscovery descriptor(s) 

Identical to TS 102 471 [1] and TS 102 592-1 [2]. 
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5.2.3.1 .3 Selecting ESG Entry from ESG Access descriptor(s) 

Identical to TS 102 471 [1] and TS 102 592-1 [2]. 

5.2.3.1 .4 Tuning to ESG announcement carousel 

Identical to TS 102 471 [1] and TS 102 592-1 [2], with the following change for Type 1 and Type 2 terminals if 
multiple ESGentries are found for the same ESG Provider URI: 

• In that case, this denotes a regionalized ESG. 

• Starting from first ESG Entry associated to a given ProviderURI, the terminal then determines for each ESG 
Entry if the associated ESG announcement carousel is transmitted or not, using an IP stream availability 
function. 

• The terminal stops parsing the ESGEntries if next ESG Entry is associated with another ESG Provider URI, or 
if two transmitted ESG announcement carousels are found. 

• If one single transmitted ESG announcement carousel is found, this is the common ESG announcement 
carousel, to be monitored. 

• If two transmitted ESG announcement carousels are found, the terminal knows that the first one appearing in 
the loop is the common carousel, and therefore the other one is the local ESG announcement carousel, to be 
monitored. 

NOTE: The terminal can also identify the common ESG announcement carousel as the carousel carried by the 
DVB service transporting also the ESG bootstrap session. 

• From the position of selected ESG Entry in the ESG Entry loop, the terminal can infer the ID of the delivery 
area of the announcement carousel. 

5.2.3.2 ESG acquisition 

5.2.3.2.1 Selecting ESG FLUTE sessions from ESG Session Partition Declaration 

Identical to TS 102 471 [1] and TS 102 592-1 [2]. 

5.2.3.2.2 Tuning to ESG FLUTE sessions 

Identical to TS 102 471 [1] and TS 102 592-1 [2]. 

5.2.3.2.3 Using ESG indexing 

Identical to TS 102 471 [1] and TS 102 592-1 [2]. 

5.2.3.2.4 ESG storage 

Identical to TS 102 471 [1] and TS 102 592-1 [2], with the following changes, in case the ESG instance (identified by 
one ProviderURI) is regionalized, as signalled by the presence of multiple ESGentries for the corresponding 
ProviderlD: 

For Type 1 terminals: 

• Implicit ESG fragment regionalization, which consists for Type 1 terminals in tagging each fragment with the 
identifier of the FLUTE session which delivered the fragment: 

How the terminal defines the identifier of a FLUTE session is implementation-dependent, however for a 
given ProviderURI this identifier must be unique given the set of {IP version, source IP address, 
destination IP address, port, TSI} found in IPstreamID declaration. 
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For Type 2 terminals: 



• Tagging of each stored fragment with the three-digit ID of the deHvery area for which this fragment is deemed 
vaHd: 

(Implicit regionalization, for fragments other than Service fragments) The deHvery area ID to be used 
for tagging is by default the ID of the deHvery area of the selected carousel (inferred from ESG Entry 
position in entry loop of ESG Access descriptor). 

(Implicit regionalization, for fragments other than Service fragments) The delivery area ID determined 
in previous step is overridden by the delivery area ID inferred from the servicelD criterion of the 
partition which declares the ESG FLUTE session delivering the fragment, under the condition that this 
delivery area ID is well-defined, which is the case if: 

■ both 'start_field_value' and 'end_field_value' of servicelD criterion are URI starting by 
"dvbshipdc:" scheme (which implies the presence of 'area999' pattern). 

■ start_field_value and end_field_value express one single value (and not a range) of delivery area 
ID. 

EXAMPLE: 

The delivery area ID would be equal to 001 if: 

start_f ield_value = "dvbipdc : //areaOOl .myprovider/" and 

end_f ield_value = "dvbipdc : //areaOOl .myprovider/Ch3 " 

But would be undefined whenever a range of arealDs is expressed: 

start_f ield_value = "dvbipdc : //areaOOl .myprovider/" and 

end_f ield_value = "dvbipdc : //areaOOS .myprovider/" 

Or when 'area999' is not following URI scheme: 

start_f ield_value = "dvbipdc : //myprovider . com/Chl" and 

end_f ield_value = "dvbipdc : //myprovider . com/Ch3 " 

(Explicit regionalization): The delivery area ID determined in previous step(s) is overridden when 
present by the delivery area ID explicitly signalled in the URI of the fragment ID itself (as defined 
above). 

5.2.3.3 ESG browsing and service consumption 

5.2.3.3.1 Displaying ESG information relevant to current location 

For Type terminal implementations, identical to TS 102 471 [1] and TS 102 592-1 [2]. However, if the ESG provider 
uses ESG instantiation mechanisms 12 and 13, this type of terminal might attempt to purchase a service bundle which 
includes not only common services but also local services. 



• 



• 



The first issue will be commercial: the user can purchase local services for which his or her terminal cannot 
access to. 

The second issue will be operational: as a Type terminal does not implement any IP stream availability 
function, it will get an error when attempting to tune to non-transmitted local IP streams (declared by 
Acquisition fragments referenced by the local Service fragments parts of the service bundle). 
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To avoid this situation: 

• ESG providers instantiating mechanisms 12 and 13 should describe the content of the service bundles very 
clearly. 

• Terminals of type might at a minimum check for the presence of a pattern /area999/ in the ID of the Service 
fragments part of a Service Bundle, and if the area ID is different from 000, do not propose the user to 
purchase this bundle. 

For Type 1 terminal implementations, identical to TS 102 471 [1] and TS 102 592-1 [2], with the following changes: 

• When tuned to a Partially Available Transport Stream, and subsequently to ProviderURI selection, the 
terminal must determine the IDs of all the ESG FLUTE sessions declared in the ESG session partition 
declaration (all of them, not just the ESG FLUTE sessions of immediate interest for the terminal). 

• Knowing this list of FLUTE session IDs, the terminal should present to the user a current ESG subset made of: 

the ESG fragments currently stored in the terminal which are tagged by any of these FLUTE session IDs. 

• The terminal must in a second stage remove from this subset the fragments which are not valid in the current 
location. This can be done for instance as follows: 

First check for the actual validity of the Acquisition fragments of the subset, which consists in verifying 
(using an IP stream availability function) if all the IP addresses given in the related SDP are really 
transmitted in the actual TS. 

Second discard from the ESG subset the invalid Acquisition fragments, as well as the invalid 
ScheduleEvent and Service fragments (i.e. which reference no valid Acquisition fragments), as well as 
the invalid Content fragments (i.e. which reference no valid Service fragment). 

For Type 2 terminal implementations, identical to TS 102 471 [1] and TS 102 592-1 [2], with the following changes: 

• When tuned to a Partially Available Transport Stream, and subsequently to ProviderURI selection, the 
terminal must determine the IDs of the delivery areas it is currently located in. This list of delivery area IDs 
includes: 

the ID of the delivery area of the selected carousel, inferred from the position of the related ESG Entry in 
the ESG Access descriptor; 

the delivery area ID "zero" (if not already included in the list); 

any delivery area ID in range 500 to 999 encountered in "servicelD" partition criteria of the ESG session 
partition declaration. 

• Knowing this list of delivery area IDs, the terminal should present to the user a current ESG subset made of: 

the ESG fragments currently stored in the terminal which are tagged by any of these delivery area IDs; 

any other fragments referenced by these fragments, and then any fragments referenced by these other 
fragments, etc. ESG instantiation mechanisms described in the present document ensure that the chain of 
fragment references can always been resolved. 

• The terminal must in a second stage block the use of the referenced Acquisition fragments which are not 
tagged by delivery area IDs. 

• As an example, in ESG instantiation mechanisms 12 and 13, the terminal on satellite cell would present: 

the common ServiceBundle fragments; 

the common and local Service fragments referenced by these common ServiceBundle fragments; 

the Acquisition fragments referenced by the common Service fragments; 

the common "interactive" Acquisition fragments referenced by the local Service fragments; 

but would block the use of the local Acquisition fragments referenced by the local Service fragments. 
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5.2.3.3.2 Accessing IPDC services from ESG 

Broadcast access to IPDC services is announced in the ESG, via Acquisition fragments and associated SDP files. At the 
time of service consumption, the question arises in which case the terminal should check (using an IP stream 
availability function) the availability of the related IP streams (audio/video streams, key streams, generic file delivery 
sessions, etc.) before tuning to them: 

• If the ESG is not regionalized. Type 0, Type 1 and Type 2 terminals do not need this check as a 
non-regionalized ESG always scopes common IP streams. 

• If the ESG is regionalized: 

A Type terminal implementation (which is not able to perform this check anyway) will safely tune to 
the announced IP streams, as all Acquisition fragments delivered in common area declare common IPDC 
services. 

A Type 1 terminal implementation must systematically check the availability of these IP streams. 

A Type 2 terminal implementation does not need to perform this check, as it is guaranteed that the 
Acquisition fragments tagged by a given delivery area ID declare IPDC streams distributed on this same 
delivery area. 

5.2.3.4 Mobility and acquisition service continuity 

For Type 0, Type 1 and Type 2 terminals moving to target cell where a different TS is transmitted: identical to 
TS 102 61 1-2 [i.4]. In most cases (and as signalled in the INT), very few IP streams should be common between source 
cell and target cell. It is unlikely also that a global ESG instance (identified by a ProviderURI) can be transmitted 
identically in two different Transport Streams, meaning ESG acquisition restart is expected when tuning on target TS. 
For Type terminals moving to target cell where same TS is transmitted: identical to TS 102 611-2 [i.4]. These 
terminals can only be tuned to IP streams carried by common DVB services, which are transmitted everywhere. Said 
otherwise, this is the handover case "same TS, change of cell_id, same or different network_id" based in NIT only. 

For Type 1 and Type 2 terminals moving to target cell where same TS is transmitted, two cases of ESG acquisition 
service continuity should be considered: 

1) The terminal is acquiring the ESG (and may consume IPDC services at the same time). 

If the set of DVB services transmitted on source and target cell are exactly the same, then handover can 
be performed on all received sessions (including the ESG ones). 

Otherwise, some ESG sessions are likely to differ from source cell to target cell, however a rerun of full 
ESG bootstrapping procedure on target cell should be avoided. Instead, the terminal should attempt to 
perform a handover on ESG sessions monitored on source cell, that are known to be transmitted on target 
cell. This typically includes the ESG bootstrap FLUTE session and the common ESG FLUTE sessions. 

The terminal should also attempt service continuity on the ESG announcement carousel, when possible. 
For this, various strategies are possible: 

a) The terminal could determine in advance (on source cell, before attempting handover) the IP 
address of ESG Announcement Carousel on target cell (according to ESG Access descriptor of 
common ESG bootstrap session, and using an IP stream availability function). This selection 
follows the principles of selection of ESG announcement carousel in actual TS. 

Two cases depending if IP addresses of source and target carousels are the same or not: 

If they are the same, service continuity for all ESG sessions (bootstrap, carousel and 
FLUTE sessions) should be attempted. 

If they are different, and since at least the ESG bootstrap FLUTE session and the 
common ESG FLUTE sessions are IP flows common to source and target cells, the 
terminal should attempt ESG acquisition service continuity on these, while tuning to 
target ESG Announcement Carousel in the background. In any case, a full ESG 
bootstrapping procedure should be avoided. 
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b) Alternatively, the terminal could avoid determining in advance (on source cell) the ESG carousel 
on target cell, by always tuning to common ESG carousel when moving on target cell. In a second 
stage (on target cell in the background), the terminal would then determine if a local ESG carousel 
is transmitted, and tune to it if there is one. This method is quite efficient for the transitions: 

"satellite -^ terrestrial" (handover on common ESG carousel, followed by carousel selection 
procedure that will indicate the local ESG carousel to tune to). 

"terrestrial -^ satellite" (tuning to common ESG carousel, followed by carousel selection 
procedure that will confirm common ESG carousel is the one to be tuned to). 

But is less efficient for the other transition: 

■ "terrestrial -^ terrestrial, different ESG carousel" (tuning to common ESG carousel, followed by 
carousel selection procedure that will select a local carousel - transition thus involving two ESG 
carousel tunings on target cell). 

NOTE: Transition "terrestrial -^ terrestrial, same ESG carousel" should occur in the situation "same DVB 
services transmitted on both source and target cell", for which there is no service continuity issue. 

2) The terminal is not acquiring the ESG (but could consume IPDC services at the same time). 

The terminal should determine if the set of DVB services being transmitted has changed or not, from 
source cell to target cell. 

If it has not changed, the terminal may defer ESG bootstrapping and acquisition. 

If it has changed, the terminal could initiate ESG bootstrapping and acquisition. 

5.3 ESG instantiation meciianisms 

This clause describes how a complete ESG (identified by one ESG Provider URI) can be instantiated in a Partially 
Available Transport Stream. This description consists in a set of instantiation mechanisms which the ESG provider may 
combine to achieve various ESG distribution scenarios. 

For the clarity of the description, a few concepts are defined: 

• Current delivery area: in the scope of the selected ESG instance (ProviderURI), delivery areas where a 
(Type 2) terminal is currently located. Current delivery areas are by definition bound to current cell. 
Practically, all the ESG and IPDC sessions instantiated in this delivery area are available to the (Type 2) 
terminal on current cell. The terminal may be located in several delivery areas at a time, and this list includes 
at least the delivery area of the selected carousel, as well as the common delivery area. 

• Neighbouring delivery area: delivery area scoped by the selected ESG instance (ProviderURI), bound to a 
neighbouring cell but not to the current cell. The (Type 2) terminal can determine the presence of neighbouring 
delivery areas by checking the availability on neighbouring cells of local carousels different from currently 
selected carousel, using an IP stream availability function as well as the ES Gentries of same ProviderlD in the 
ESG Access descriptor. 

• Valid fragment: ESG fragment which the terminal can safely present to the user with regard to the IPDC 
services available on the current cell. Technically, a fragment is valid if it is tagged by the ID of one of the 
current delivery areas. 



• 



Common fragment: ESG fragment valid in the common delivery area, i.e. on all the cells where the ESG 
instance is transmitted. 

Local fragment: ESG fragment valid in a local delivery area. 

Complete ESG: consistent ESG instance identified by one ProviderURI. The complete ESG spans over one, 
several or all cells where the TS is transmitted. Typically, only self-contained ESG subsets of this complete 
ESG are transmitted on a given cell. 
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• ESG subset (or regionalized ESG): consistent subset of a complete ESG, aiming to announce the IPDC 
services available on a defined list of delivery areas. This subset is self-contained, i.e. fragments referenced by 
the fragments of this subset are also part of the subset. An ESG subset has no identifier. When moving from 
one cell to another, the terminal would typically acquire a new ESG subset. ESG subsets acquired in the 
different cells where the ESG is transmitted can be safely merged into the terminal so to construct the 
complete ESG. 

• Current ESG subset: ESG subset delivered on the current delivery area(s) aiming to announce the IPDC 
services available on these delivery areas. 

• Neighbouring ESG subset: ESG subset delivered on the current delivery area aiming to announce the IPDC 
services available on a neighbouring delivery area where the ESG instance is also transmitted. 

• Common ESG subset: ESG subset aiming to announce the IPDC services available on common delivery area. 

• Local ESG subset: ESG subset aiming to announce the IPDC services available on some local delivery 
area(s). 

The described instantiation mechanisms pay special attention to ESG consistency, so to guarantee that any type of 
terminal cold-bootstrapping on any cell, and with no interaction channel capabilities, can still acquire a self-contained 
consistent ESG subset announcing all the IPDC services available on this cell. To achieve ESG subset consistency, the 
following rules apply: 

• A fragment distributed in a set of delivery area(s) can only reference fragments distributed in this set. 

• For a given ESG (Provider URI), fragments identified by a given pair {fragment ID, version} and distributed 
in delivery areas must all be equal bitwise. 

5.3.1 ESG instantiation mechanism 1 



Title 


Delivering a common ESG subset, for minimal announcement of 
common programs (available everywhere) 


Usage 


A user cold-bootstrapping on satellite cell can discover all common programs, and 
purchase access to them. 


Implementations 


Server: Type and Type 1 . 
Terminal: Type 0, Type 1 and Type 2. 


Technical 
realization 


Common ESG subset is delivered by so-called common ESG FLUTE sessions, targeting 
common delivery area. Common ESG FLUTE sessions are announced by common ESG 
carousel, and must be announced also by each local ESG carousel. In order to save 
satellite bandwidth, common ESG FLUTE sessions are typically partitioned using « time » 
criterion, so to limit time depth of common ESG subset 
(e.g. < 3 days). 

Type 1 servers must explicitly tag common Service fragments with delivery area ID 'zero'. 
Otherwise (for other types of fragments), implicit ESG regionalization is sufficient. 


Comments 


For ESG consistency reasons, a common ServiceBundle cannot reference local Service 
fragments, so a mixed « common + local » Service Bundle cannot be part of this common 
ESG subset. This means that a terminal cold-bootstrapping on satellite cell would first 
subscribe to a common ServiceBundle, and when moving to a terrestrial cell, would then 
subscribe to a local ServiceBundle encompassing both common and local IPDC services. 
Note that common ServiceBundles should always be instantiated (even if common+local 
ServiceBundles are besides available on local areas) for two reasons: first, a Type 
terminal will never see the common+local ServiceBundles, second a Type 1 or Type 2 
terminal cold-bootstrapping on satellite must have a means to purchase access to the 
common IPDC services. 


Dependencies 


None. 


Status 


This mechanism must be used by ESG providers. 


Example 


See figure 2. 
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Delivery Area 000 (Common) 



ESG Announcement Carousel 



IPstreamID 1 

servicelD=/areaOOO/Ch1 

timeOd 



Delivery Area 001 (Local) 



ESG Announcement Carousel 1 



IPstreamID 1 

servicelD=/areaOOO/Ch1 

timeOd 



IPstreamID 2 

servicelD=/area001/Ch2 

time=all 




Purchase ^ PurchaseChannel | 
ESG FLUTE session 1 



Purchase ^ PurchaseChannel | 
ESG FLUTE session 2 



Figure 2: ESG instantiation mechanisms 1, 2, 3 and 4 



5.3.2 ESG instantiation mechanism 2 



Title 


Delivering a local ESG subset, for full announcement of local programs available on 

current terrestrial reception 


Usage 


The user can discover and access to all local programs available on current terrestrial 
reception. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 and Type 2. 


Technical 
realization 


The fragments of this local ESG subset are delivered in ESG FLUTE sessions belonging to 

the delivery area of the local « active » ESG carousel. 

Type 1 servers must explicitly tag the local Service fragments with delivery area IDs in the 

range of 001 to 499. Otherwise (for other types of fragments), implicit ESG regionalization is 

sufficient. 


Comments 


When mechanisms 3 and 4 are not used, common and local ESG subsets are totally 
independent. Still, they are part of the same ESG instance, identified by ESG Provider URI. 


Dependencies 


None. 


Status 


This mechanism must be used by ESG providers which announce local programs. 


Example 


See figure 2. 



5.3.3 ESG instantiation mechanism 3 



Title 


Merging common and local service bundles 


Usage 


Reduce the number of service bundles presented to the user. Using this mechanism, one 
single (local) Service Bundle can encompass all common and local programs available on 
current terrestrial reception. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 and Type 2. 


Technical 
realization 


The same local ServiceBundle fragment is referencing common Service fragments as well as 
local Service fragments. 


Comments 


For ESG consistency reasons, the other way around is not possible (i.e. a common 
ServiceBundle fragment cannot reference local Service fragments). 


Dependency 


This mechanism needs mechanisms 1 and 2 to be deployed also. 


Status 


This mechanism should be used by ESG providers which announce bundles mixing common 
and local services. 


Example 


See figure 2. 
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5.3.4 ESG instantiation mechanism 4 



Title 


Sharing common Purchase Channel information 


Usage 


Reduce the number of PurchaseChannel entry points, while saving terrestrial bandwidth. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 and Type 2. 


Technical 
realization 


Purchase fragments delivered in local ESG FLUTE sessions can reference a common 
PurchaseChannel fragment. Transmission of PurchaseChannel fragments in local ESG 
FLUTE sessions can be avoided this way. 


Dependencies 


This mechanism needs mechanisms 1 and 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See figure 2. 



5.3.5 ESG instantiation mechanism 5 



Title 


Complementing the common ESG subset on terrestrial path 


Usage 


On terrestrial cell, ESG announcement of common services is provided to user with a greater 
time depth (greater than on satellite cell). 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 and Type 2. 


Technical 
realization 


A local ESG FLUTE session carries fragments belonging to common ESG subset. In local 
ESG carousel, partition criteria for this FLUTE session are « servicelD » of a common ESG 
Service fragment, and « time » (e.g. > 3 days). Possible common fragments delivered in this 
FLUTE session can be Acquisition, Content and ScheduleEvent fragments. 
NOTE: Since common Service fragments are tagged by delivery area ID 'zero' (see 

instantiation mechanism 1), the servicelD criterion in local partition declaration is 

tagged by delivery area ID 'zero' as well. 


Comments 


Implicit ESG regionalization is sufficient for the fragments delivered this way. 


Dependencies 


This mechanism needs mechanisms 1 and 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See figure 3. 



Delivery Area 000 (Common) 



Delivery Area 001 (Local) 



ESG Announcement Carou sel 

IPstreamID 1 

service! D=/areaOOO/Cli 1 

time<3d 



ESG Announcement Carousel 1 



IPstreamID 1 

service! D=/areaOOO/Cli 1 
time <3d 



IPstreamID 3 

servicelD=/areaOOO/Ch1 

time>3d 



Acquisition 



T 



Service ID=/areaOOO/Ch1 k- 



Content 



ServiceBundle 



I 



ScheduleEvent 



I 



Purcliase ^ PurchaseChannel 
ESG FLUTE session 1 



XIX 



Acquisition 



Content 



ScheduleEvent 



ESG FLUTE session 3 



Figure 3: ESG instantiation mechanism 5 
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5.3.6 ESG instantiation mechanism 6 



Title 


Announcing global terrestrial services 


Usage 


Some IPDC services not transmitted on satellite cell may happen to be available on most - if 
not all - terrestrial cells. Instead of instantiating these IPDC services in each local delivery 
area, a separate local delivery area can be defined to instantiate once these IPDC services, 
local delivery area to be bound to most terrestrial cells. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 and Type 2. 


Technical 
realization 


A global-terrestrial delivery area is specifically created for the distribution of programs 
available on most terrestrial cells but not on satellite cell. This delivery area instantiates also 
ESG FLUTE sessions with fragments announcing these programs, but no ESG 
announcement carousel. Instead, it is up to the ESG carousels of local-terrestrial delivery 
areas to announce these ESG FLUTE sessions. 


Comments 


Type 1 servers must explicitly tag global terrestrial Service fragments with delivery area IDs 
in the range of 500 to 999. Otherwise (for other types of fragments), implicit ESG 
regionalization is sufficient. 

Advantage of this mechanism is: better grouping of ESG data and IPDC service distribution. 
Drawback is: increase of PMT bitrate on terrestrial path. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


S See figure 4. 



Delivery Area 001 (Local) 



ESG Announcement Carousel 1 

IPstreamlD2 \ IPstreamlD4 

servicelD=/area001/Ch2 servicelD=/area500/Ch4 

time=all time=all 



Delivery Area 500 (Local) 




ESG FLUTE session 2 



PurchaseChannel ^ Purchase ^^V^^^PurchaseChannel ^ Purchase 



ScheduleEvent 



ServiceBundle 



ESG FLUTE session 4 



Figure 4: ESG instantiation mechanisms 6, 7 and 8 



5.3.7 ESG instantiation mechanism 7 



Title 


Bundling local and global terrestrial services 


Usage 


Reduce the number of service bundles presented to the user. Using this mechanism, one 
local-terrestrial Service Bundle can encompass all local and global terrestrial programs 
available on current terrestrial cell. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 and Type 2. 


Technical 
realization 


The same local-terrestrial ServiceBundle fragment is referencing global-terrestrial Service 
fragments as well as local-terrestrial Service fragments. 


Comments 


For ESG consistency reasons, the other way around is not possible (i.e. a global-terrestrial 
ServiceBundle fragment cannot reference local-terrestrial Service fragments). 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism should be used by ESG providers. 


Example 


See figure 4. 
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5.3.8 ESG instantiation mechanism 8 



Title 


Sharing global-terrestrial Purchase Channel information 


Usage 


Reduce the number of PurchaseChannel entry points. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 and Type 2. 


Technical 
realization 


Purchase fragments delivered in local-terrestrial ESG FLUTE sessions can reference a 
global-terrestrial PurchaseChannel fragment. Transmission of PurchaseChannel fragments in 
local-terrestrial ESG FLUTE sessions can be avoided this way. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See figure 4. 



5.3.9 ESG instantiation mechanism 9 



Title 


Delivering a minimal local ESG subset of a neighbouring delivery area 


Usage 


Terminal is aware of the presence of a neighbouring delivery area (i.e. using ESG Access 
descriptor and IP stream availability function, it can determine the availability of another local 
announcement carousel on a neighbouring cell), and acquires silently on current local delivery 
area a minimal ESG subset valid for the neighbouring delivery area. When moving to 
neighbouring cell, the available programs can be presented immediately to the user using this 
minimal ESG subset. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 (must perform systematic IP stream availability 

check) and Type 2. 


Technical 
realization 


On the current local delivery area, the ESG carousel announces specific ESG FLUTE 
sessions delivering the ESG subset of the neighbouring delivery area. Type 1 servers must 
explicitly tag the local Service fragments of this ESG subset with delivery area IDs in the 
range of 1 to 49. Otherwise (for other types of fragments in this subset), implicit ESG 
regionalization is sufficient. 


Comments 


Implicit ESG regionalization is here sufficient. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See Figure 5. 



Delivery Area 001 (Local) 



ESG Announcement Carousel 1 



IPstreamID 2 IPstreamID 5 

service! D=/area001/Cli2 set 

time=all time<1h 

I 




PurchaseChannel ~\^ Purchase 
ESG FLUTE session 2 



I PurchaseChannel^^ Purchase 
ESG FLUTE session 5 



Delivery Area 002 (Local) 
ESG Announcement Carousel 2 



IPstreamID 6 

time=all 
I 



Acquisition 



Service ID=/area002/Ch5 



t , t 

Content 



T 



ScheduleEvent ServiceBundle 

, t 

PurchaseChannel ~\^ Purchase 
ESG FLUTE session 6 



Figure 5: ESG instantiation mechanisms 9 and 10 



ETSI 



28 



ETSI TS 102 592-2 V1.1.1 (2009-07) 



5.3.10 ESG instantiation mechanism 10 



Title 


Bundling the offering of IPDC services available in different local delivery areas 


Usage 


Reduce the number of service bundles presented to the user. Using this mechanism, one 
local Service Bundle can encompass programs of current local delivery area, and programs of 
a neighbouring local delivery area, for which local ESG subset is besides delivered in current 
local delivery area. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 (must perform systematic IP stream availability 

check) and Type 2. 


Technical 
realization 


A local ServiceBundle fragment in current local delivery area is referencing Service fragments 
delivered in this same delivery area, some being valid on current delivery area, others being 
valid in another local delivery area. 


Comments 


For ESG consistency reasons, the other way around is not possible (i.e. a global-terrestrial 
ServiceBundle fragment cannot reference local-terrestrial Service fragments) 


Dependencies 


This mechanism needs mechanism 9 to be deployed also. 


Status 


This mechanism should be used by ESG providers. 


Example 


See Figure 5. 



5.3.1 1 ESG instantiation mechanism 1 1 (not recommended) 



Title 


Passively delivering fragments of neighbouring local services 


Usage 


The user can quickly visualize which local programs are available when moving to a 
neighbouring local delivery area. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 (must perform systematic IP stream availability 

check) and Type 2. 


Technical 
realization 


In the ESG FLUTE sessions of current local delivery area are also delivered a few fragments 
that are only valid for neighbouring delivery areas. These fragments are explicitly 
regionalized. The terminal stores them without too much reasoning. They may be used later 
to resolve dependencies between fragments (like Mechanism 10) or to initialize ESG 
acquisition when moving to a neighbouring delivery area. 


Comments 


This mechanism is problematic because the servicelD which the neighbouring fragments 
relate to is not declared in the ESG partition declaration. Unless indexing is used, the terminal 
cannot know in which FLUTE session these neighbouring fragments are delivered. 
Also, these neighbouring fragments do not necessarily constitute a consistent subset on their 
own (although they might help local ESG subset of current delivery area(s) to remain 
consistent). Consistency can easily be broken. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism should not be used by ESG providers. 


Example 


See figure 6. 



Delivery Area 001 (Local) 



ESG Announcement Carousel 1 



IPstreamID 2 

service! D=/area001/Cli2 

time=all 



Explicit ESG fragment 
regionalization 




PurchaseChannel ^ Purchase 



PurchaseChannel ^ Purchase 



ESG FLUTE session 2 



Delivery Area 002 (Local) 



ESG Announcement Carousel 2 



IPstreamID 6 
service! D=/area002/Cfi5 



Acquisition 



Service ID=/area002/Ch5 

t , t t 

Content 



T 



ScheduleEvent ServiceBundle 

, t 

PurchaseChannel ^ Purchase 
ESG FLUTE session 6 



Figure 6: ESG instantiation mechanism 11 (not recommended) 
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5.3.12 ESG instantiation mechanism 12 



Title 


Presenting everywhere some minimal information on all 
common and local IPDC services. 


Usage 


The user is presented with an elementary description of all common and local IPDC services 
(even on satellite cell). Further display indication shows which services are available or not on 
current cell. The user is even able to purchase a mixed bundle of common/local services on 
satellite cell. 


Implementations 


Server: Type 1 . 

Terminal: Type (must not display service bundles which include local services), Type 1 

(must perform systematic IP stream availability check) and Type 2. 


Technical 
realization 


A dedicated ESG FLUTE session is instantiated in common delivery area to deliver all the 
local Service fragments available on local delivery areas for this ESG instance (ProviderURI), 
as well as all the Acquisition fragments referenced by these Service fragments (for ESG 
consistency reasons). The servicelD partition criterion of this session expresses a range of 
local delivery area IDs. 


Comments 


All fragments delivered this way must be explicitly regionalized. 

Local Service and Acquisition fragments delivered on common delivery area must be totally 
identical as those delivered on local delivery areas. This implies that these local fragments 
are explicitly regionalized in both common and local services. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism is encouraged to be used by ESG providers. 


Example 


See figure 7. 



Delivery Area 000 (Common) 



ESG Announcement Carousel 



IPstreamID 1 

servicel D=/areaOOO/Ch 1 
time<3d 



IPstreamID 7 
servicelD= range in 
/area001..area999/ 



Explicit ESG fragment 
regionalization 




PurchaseChannel ^ Purchase 
ESG FLUTE session 1 



Acquisition 



ESG FLUTE session 7 



Figure 7: ESG instantiation mechanism 12 and 13 
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5.3.13 ESG instantiation mechanism 13 (IPDC phase 2) 



Title 


Giving alternative point-to-point access to local broadcast IPDC services on cells 
(especially satellite cell) where these local broadcast services are not available 


Usage 


On satellite cell, the user has no broadcast access to local TV channels, but can still access 
to them using point-to-point bearers. 


Implemen- 
tations 


Server: Type 1 . 

Terminal: Type (must not display service bundles which include local services). Type 1 

(must perform systematic IP stream availability check) and Type 2. 


Technical 
realization 


If the common ESG FLUTE session which delivers local Service fragments, a common 
Acquisition fragment of DeliveryChannel type "interactive" is delivered also, pointed by a local 
Service fragment. This Acquisition fragment is explicitly regionalized (i.e. acquisitionID 
contains the ID of common delivery area, i.e. zero). 


Comments 


All fragments delivered this way must be explicitly regionalized. 

For ESG consistency reason, "interactive" Acquisition fragments delivered in common 

delivery area must be delivered also on the local delivery areas where the local Service 

fragments are available (bitwise identical Acquisition fragments, meaning in particular tagged 

also by common delivery area ID). 

This instantiation mechanism is provided for information, as Acquisition fragments of 

DeliveryChannel type "interactive" are not in the scope of the present document. 


Dependencies 


This mechanism needs mechanisms 1 and 12 to be deployed also. 


Status 


This mechanism should be used by ESG providers when broadcast services not available on 
current cell are wanted to be accessed via interactive channel. 


Example 


See figure 7. 



5.4 Summary change from IPDC phase 1 

For ESG for DVB-SH, changes that are perceptible to an IPDC phase 1 terminal implementation are the following: 

• For Type 0, Type 1 and Type 2 terminal implementations, if the ESG is not regionalized: none 

• For Type terminal implementations, if the ESG is regionalized: 

Display-level filtering of service bundles which include at least one local IPDC service. Practically, it 
means that terminal must hide ServiceBundle fragments which reference one or more local Service 
fragments (i.e. servicelD explicitly regionalized, with a delivery area ID in the range of 1 to 999). 

• For Type 1 and Type 2 terminal implementations, if the ESG is regionalized: 

Addition of an "IP stream availability function", which checks in the received TS the actual transmission 
of some given IP stream(s) of some given IP platform ID. For this check, this function especially relies 
on cell_id, INT and SDT/service availability descriptors. In the present document it is assumed to be a 
low-level function exposed to the application layer. 

In the ESGAccessDescriptor, multiple ESGEntries for the same ESG Provider ID. Selection of proper 
ESG Entry (i.e. ESG announcement carousel) made using IP stream availability function. 

ESG fragment regionalization, consisting in tagging by an ID each stored fragment, according to implicit 
signalling (for Type 1 terminal: FLUTE session ID; for Type 2 terminal: delivery area ID given by ESG 
Entry position or by servicelD criterion) or explicit signalling (for Type 2 terminal: delivery area ID 
included in the fragment ID URI) 

User presented with a regionalized view of ESG according to the current FLUTE sessions transmitted for 
the selected instance (Type 1 terminal) or to the current delivery areas where the terminal is located 
(Type 2 terminal). 

Service continuity optimizations when terminal is acquiring the ESG while moving to another cell. 
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Annex A (normative): 

Types of ESG implementations 



This annex details several possible levels of ESG implementations for a DVB-SH ESG provider (ESG server) and for a 
DVB-SH terminal (ESG client). 

Types of server implementations: 



Type 


Deployed ESG mechanisms 


Related 
scenarios 


Type 


Strict instantiations of DVB-H IPDC phase 1 ESG as specified in 
TS 102 471 [1] and TS 102 592-1 [2]. 


1 


Type 1 


Common and local announcement carousels, unlimited area-based 
fragment tagging, FLUTE sessions delivering valid fragments and 
(eventually) invalid fragments. 


1 to 13 



Types of terminal implementations: 



Type 


Supported mechanisms 


Type 


ESG client strictly conforming to DVB-H IPDC phase 1 as specified in TS 102 471 [1] and TS 
102 592-1 [2], plus an eventual filtering on the presented service bundles (see section 
5.2.3.3.1) 


Type 1 


Selection of announcement carousel based on an IP stream availability function, FLUTE- 
session based fragment tagging, check of IPDC streams availability based on an IP stream 
availability function 


Type 2 


Selection of announcement carousel based on an IP stream availability function, area-based 
fragment tagging 



NOTE: Type 1 and Type 2 terminal implementations are assumed to achieve the same level of functionality. They 
just differ by the technical realization. 

These server and terminal implementations can co-exist with no interoperability issues. Table below indicates the 
limitations implied by some combinations: 



Server 


Terminal 


TypeO 


Type1 


Type 2 


Type 


OK 


OK 


OK 


Type 1 


OK, however terminal will not 
see the local IPDC services. 
Also terminal must implement 
a means to hide to the user 
the service bundles which 
include local IPDC services 
(security against potential 
deployments of instantiations 
mechanisms 12 and 13). 


OK, however terminal needs 
to check IPDC sessions 
availability. 


OK 



Recommended server implementations is: 

• Preferably Type 1 . 
Recommended terminal implementations are: 

• Preferably Type 2; 

• Eventually Type 1 if the terminal can implement a fast IP stream availability function. This speed is especially 
critical when the terminal needs to display the user which IPDC services are available on current cell (then the 
terminal needs to check for the availability of all the IPDC streams scoped by the Acquisition fragments 
tagged by the identifiers of the current ESG FLUTE sessions). 
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Annex B (informative): 

DVB-SH physical layer options for ESG 

B.1 SH-A SFN configuration 

As presented in figure B.l, the DVB-SH TS 1 being sent on the satellite will be received in exactly the same way 
wherever the terminal is located. 

H ybrid frequency ^ Non-hybrid frequencies 



Satellite geographical area 
Same geographical local area 



5 MHz ^5 MHi 
^M 



5 MHz ^ 
-^ < P- 



F1 (satellite) 
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SH-A 
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OFDM 


Mod sat (celllD 1 ) 


X 




- 


Mod CGC CcelllD 1 ) 


X 


- 


- 


Mod CGC (celllD 2-ter) 


- 


X 


- 


Mod CGC CcelllD 3-ter) 






X 



Reception conditions 








Options 


DVB-H TS 


Unicast 


SFN Rx 1 


X 


X 


X 






SFN Rx 2 


X 


X 








SFN Rx 3 


X 










SFN Rx 4 




X 








SFN Rx 5 




X 


X 







Figure B.1 : An example of SFN reception 



B.2 SH-A non-SFN and SH-B configurations 
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Figure B.2: An example of non-SFN reception 
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